\chapter{Анализ данных}
\pagenumbering{arabic}

% % Лицензия на материалы этого текст
% 
% Материалы сайта "Записки дебианщика" написаны virens и доступны на условиях лицензии Creative Commons Attribution-Non-Commercial-Share Alike 3.0 Unported License. Вы можете копировать, распространять, показывать эту работу, и создавать производные работы в некоммерческих целях на условиях:
% 
% 1) обязательной ссылки на автора (virens, http://mydebianblog.blogspot.com/) и
% 
% 2) распространении любых производных работ на условиях этой же лицензии (ссылка на эту лицензию 
% обязательна!).
% 
% Пожалуйста соблюдайте условия лицензии.
% 
% This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. 
\section{Свободные утилиты восстановления данных}
Задача: восстановить информацию с повреждённого CD-диска, копирование с которого прерывается из-за ошибок чтения.

\subsection{Утилита dd}
Старая, как сам UNIX, утилита, входящая решительно в любой нормальный дистрибутив UNIX-основанных систем. Более того, на блоге уже упоминался вариант её использования для проверки дисков. Теперь она послужит нам для нужд восстановления.
Собственно, её использование приведёт к копированию данных, несмотря на ошибки:

\begin{lstlisting} 
$ dd if=/dev/cdrom of=~/bad.iso bs=2048 conv=noerror
\end{lstlisting}

Игнорирование ошибок чтения обеспечивает именно последний параметр, при этом вы будете наблюдать многочисленные сообщения об ошибках.

\subsection{Утилита recoverdm}
В комплект поставки дистрибутивов она входит редко, но распространяется под лицензией GPL, и скачать её отсюда.
Требует рутовых прав, так как использует некоторое "трюкачество", например сброс состояния контроллера и чтение "сырых" данных (RAW-data). Обеспечивает большую точность восстановления, чем dd, и больший набор параметров. Однако работает гораздо медленнее dd в силу того, что гораздо большее количество попыток чтения совершается. Способна восстанавливать данные с дискет, CD/DVD и жёстких дисков. Кроме того, поставляется с утилитой mergebad, которая полезна в случае, например, когда есть несколько компакт-дисков, и все они битые, а информация на них распределена.
Компиляция из исходников посредством команды make не представляет никакой трудности. Нужно поставить на ней соответствующие права и выполнить команду:

\begin{lstlisting} 
$ recoverdm -t 20 -i /dev/hda -o bad.iso -l badsectors.bad -n 10 -r 12
\end{lstlisting}

После чего начнётся медленное и печальное восстановление. Лучше всего ставить эту процедуру на ночь, так как при сколько-нибудь обширных сбоях чтения компакт-дисков такое считывание может занять несколько часов (мой злосчастный миморекс читался 7 часов).
В процессе считывания вы будете видеть в консоли такие вот сообщения:

\begin{lstlisting} 
Trying RAW read...
Tried reading 10 times, failed doing that. Continuing...
error at 732188672 bytes, retrying: 1
error at 732188672 bytes, retrying: 2
error at 732188672 bytes, retrying: 3
seek to end...
error at 732188672 bytes, retrying: 4
resetting device...
error at 732188672 bytes, retrying: 5
resetting controller...
error at 732188672 bytes, retrying: 6
error at 732188672 bytes, retrying: 7
error at 732188672 bytes, retrying: 8
error at 732188672 bytes, retrying: 9
error at 732188672 bytes, retrying: 10
Trying RAW read...
Tried reading 10 times, failed doing that. Continuing...
\end{lstlisting}

которые будут тем многочисленнее, чем больше запорчен диск и чем больше вы поставили попыток чтения. Естественно, утилита не волшебная, и те данные, которые восстановить не удалось, просто заменяет пустыми блоками. Если на диске было много фотографий, потерю десятка вы переживёте менее болезненно, чем всего диска целиком.
Восстановление этой программой занимает существенно больше времени, чем dd. Не ждите, что диск с обширными повреждениями (более 10\% секторов) проутюжится меньше, чем за 7-8 часов (при многократном считывании с параметрами, указанными выше). Но есть проверенный способ: ставим на ночь и идём спать...



\section{Глубокий анализ данных, Эпизод 1: foremost}
Есть ситуации: ваша флешка начинает помирать, диск плохо читается и на нём важные данные, или вы пришли к какому-нибудь недругу и подозреваете, что у него на винчестере есть данные, которые вам нужны, а он их показывать не хочет. 

Имеется класс программ "судебного анализа данных" (forensic analisys), позволяющих без шума и пыли (и ректальной имплантации горячих паяльников) выудить данные, даже если они хитро записаны.

\subsection{Что есть для этого в Дебиан?}
Чего только не найдёшь в Дебиановском репозитории! Например, очень и очень интересная программа foremost. Она позволяет искать файлы на сменных носителях / внутри образов дисков по hex-данным, характерным заголовкам и окончаниям. В Sarge версия довольно старая, но с сайта можно скачать тарболл и скомпилировать его.

\subsection{Foremost в действии}
Отлично, программа собрана и установлена, с требуемого носителя содран образ при помощи dd, теперь осталось поискать там файлы.

Попробуем поискать файлы, замаскированные под другой формат.
Берём флешку, втыкаем и не монтируем - пробуем выдрать оттуда файлы типа doc, один из которых переименован в jpg (наивный юноша...):

\begin{lstlisting} 
$ foremost -t doc -o /opt/foremost-1.3/output/ -i /dev/sdf
\end{lstlisting}

После чего идём в подкаталог ../output и наблюдаем радостную картину - файлик обнаружился. А вот и отчёт программы:

\begin{lstlisting} 
Foremost version 1.3 by Jesse Kornblum, 
Kris Kendall, and Nick Mikus
Audit File

Foremost started at Sat Dec 16 21:48:07 2006
Invocation: ./foremost -t doc 
-o /opt/foremost-1.3/output/ -i /dev/sdf
Output directory: /opt/foremost-1.3/output
Configuration file: /opt/foremost-1.3/foremost.conf
----------------------------------
File: /dev/sdf
Start: Sat Dec 16 21:48:07 2006
Length: 15 MB (16121856 bytes)

Num (bs=512) Size Offset

0: 129.jpg 155 KB 66048
Finish: Sat Dec 16 21:48:12 2006

1 FILES EXTRACTED

doc:= 1
----------------------------------
\end{lstlisting}

Имя не сохранено, но содержимое в порядке. Нагретый паяльник и утюг можно отложить в сторону. :-)

Другой пример. Пусть хакер Нео хочет скрытно передать товарищу Морфею диск с изображением кодов к Матрице (фотографией голой Тринити). Для этого можно схитрить: приказывать писать программе cdrecord не iso-образ, а просто файл:

\begin{lstlisting} 
$ cdrecord -v speed=0 dev=ATAPI:0,0,0 matrixcodes
\end{lstlisting}

На другом конце Морфей делает

\begin{lstlisting} 
$ dd if=/dev/cdrom bs=2048 of=~/temp/matrix.jpg
\end{lstlisting}


Но вот всех застукал агент Смит, приволок в отделение и ласково спрашивает, что на болванке. Хакер Нео с ясными глазами говорит почти правду - ничего, болванка пустая (ясное дело, что "в лоб" такая болванка не читается). Агент Смит знает Линукс и поэтому он набирает в консоли:

\begin{lstlisting} 
$ foremost -t all -o ~/output/ -i /dev/hda
\end{lstlisting}

И выуживает из диска крамольные данные: в подкаталоге ..output/ появляется файл audit.txt следующего содержания:

\begin{lstlisting} 
Foremost version 1.3 by Jesse Kornblum, 
Kris Kendall, and Nick Mikus
Audit File

Foremost started at Sat Dec 16 22:15:26 2006
Invocation: ./foremost -t all 
-o /opt/foremost-1.3/output/ -i /dev/hda
Output directory: /opt/foremost-1.3/output
Configuration file: /opt/foremost-1.3/foremost.conf
----------------------------------
File: /dev/hda
Start: Sat Dec 16 22:15:26 2006
Length: 604 KB (618496 bytes)

Num (bs=512) Size Offset

0: 0.jpg 88 KB 0
Finish: Sat Dec 16 22:15:28 2006

1 FILES EXTRACTED

jpg:= 1
----------------------------------

Foremost finished at Sat Dec 16 22:15:28 2006
\end{lstlisting}


и каталог ..output/jpg/ с этим файлом...

Ещё немного поигравшись с программой, можно сказать следующее. Сразу, без дополнительных танцев, находит foremost графические файлы tif, jpg, png, bmp, звуковые файлы wav, виндовые exe-шники, все офисные форматы (мелкоОфиса и ОпенОфиса), архивы rar и zip и многое другое. Линуксовые архивы типа bzip2 и p7zip "в лоб" программа не берёт, но это дело не сильно облегчает, так как, задавшись целью, можно и их выдрать с диска.

\subsection{Аналогичные программы}
Такие программы особенно не афишируются, и крайне неохотно раздаются за просто так. Или надо оставлять свои паспортные данные и доказывать, что вы работаете в полиции, в суде или в КГБ :-) Но всё-таки кое-что имеется. Это проприетарные Safeback, Encase, safecopy, dvdisaster и некоторые другие. Особые параноики полагают, что старый-добрый dd тоже является программой из этой же серии.




\section{Глубокий анализ данных, Эпизод 2: The Sleuth Kit}
Продолжая тему о программах анализа данных, в этом посте пойдёт речь о семействе утилит судебного анализа (forensic analys) The Sleuth Kit. В дистрибутив Debian оно пока не входит (в Sarge v3.1r1 во всяком случае), но это не мешает скачать сырцы с сайта проекта и собрать самостоятельно.

\subsection{Установка}
Для того, чтобы начать использовать The Sleuth Kit, требуется распаковать тарбол в любую директорию и просто набрать в ней make. Для сборки программы нужны библиотеки SSL, которые нужно предварительно поставить.

\begin{lstlisting}
# apt-get install libssl0.9.7 libssl-dev
\end{lstlisting}

После того, как всё настроится и установится, можно приступать к сборке:

\begin{lstlisting}
# make
\end{lstlisting}


В результате должно всё собраться, а утилиты появятся в подкаталоге ../bin, который до сборки был пуст. После сборки там появится много утилит, часть которых будет описываться далее.


\subsection{Ищем и находим данные}
После установки в вашем распоряжении окажется почти три десятка утилит, способных дать исчерпывающую информацию и том, что и как записано на носителе. Разумеется, утилиты прекрасно работают с raw-данными, полученными dd или recoverdm, о которой уже было написано.
Следует отметить, что если программа foremost предназначена скорее для экспресс-анализа и представляет собой утилиту вида "всё в одном флаконе", то The Sleuth Kit это набор утилит для более глубокого исследования данных. Но это лучше показать на примере, в котором используется версия 2.07.

\subsection{Пример}
Пусть имеется образ флешки в файле 1.img, и на ней есть данные, которые нужно извлечь без монтирования. Для этого сначала смотрим, какие структуры данных вообше присутствуют на диске - это делает утилита mmls - media management lister. Она показывает разметку диски, в том числе пустые области (unallocated spaces), а так же адреса начала и окончания партиций.
Поддерживаются следующие типы партиций:

\begin{lstlisting}
dos (DOS-based partitions [Windows, Linux, etc.])
mac (MAC partitions)
bsd (BSD Disklabels [FreeBSD, OpenBSD, NetBSD])
sun (Sun Volume Table of Contents (Solaris))
gpt (GUID Partition Table (EFI))
\end{lstlisting}


Так, применяем mmls для того, чтобы узнать, какое расположение и тип партиций:

\begin{lstlisting}
$ mmls 1.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000031 0000000031 Unallocated
02: 00:00 0000000032 0000031359 0000031328 DOS FAT12 (0x01)
03: ----- 0000031360 0000031487 0000000128 Unallocated
\end{lstlisting}


Всё верно, досовская файловая система на флешке (выделение полужирным - моё). Теперь известно, откуда она начинается и где заканчивается - эта информация нужна для работы других утилит.

Отлично, теперь мы знаем тип файловой системы и где она располагается. Посмотрим, как много данных на ней есть и что мы может оттуда выдрать - в этом деле нам поможет другая утилита, fsstat. Вызываем её, сообщая сведения, полученные от mmls:

%А зачем "penta4@penta4rce" ?
\begin{lstlisting} 
penta4@penta4rce:~/temp $ fsstat -f fat -o 0000000032 1.img 
FILE SYSTEM INFORMATION
----------------------------------
File System Type: FAT12

OEM Name: +/J8LIHC
Volume ID: 0x913
Volume Label (Boot Sector): SANVOL
Volume Label (Root Directory):
File System Type Label: FAT12

Sectors before file system: 32

File System Layout (in sectors)
Total Range: 0 - 31327
* Reserved: 0 - 0
** Boot Sector: 0
* FAT 0: 1 - 12
* FAT 1: 13 - 24
* Data Area: 25 - 31327
** Root Directory: 25 - 56
** Cluster Area: 57 - 31320
** Non-clustered: 31321 - 31327

METADATA INFORMATION
----------------------------------
Range: 2 - 500226
Root Directory: 2

CONTENT INFORMATION
----------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 2 - 3909

FAT CONTENTS (in sectors)
----------------------------------
57-64 (8) -> EOF
65-80 (16) -> EOF
81-88 (8) -> EOF
89-96 (8) -> EOF
97-408 (312) -> EOF
409-688 (280) -> EOF
689-696 (8) -> EOF
697-1000 (304) -> EOF
\end{lstlisting}


Отлично, теперь мы знаем, сколько файлов записано и где они расположены. Самое время посмотреть на структуру каталогов и файлов, начиная с корневого каталога. Для этого воспользуемся утилитой fls, которая показывает не только записанные, но и удалённые файлы. Посмотрим, что есть в корневом каталоге:

\begin{lstlisting}
$ fls -f fat -o 0000000032 1.img
d/d 3: DCIM
d/d 4: SCENE
r/r * 6: raw1.bz2
r/r 8: cdpocket.pdf
r/r 10: raw1
\end{lstlisting}


Чудесно, знаем не только имена файлов, но и их смещения, которые нам потребуются, чтобы прочесть файлы. Звёздочка означает, что файл удалён: но его можно попробовать восстановить, если после удаления не проводилось интенсивного перезаписывания файлов.
Если файлов много, или они в каталогах, и требуется найти смещение файла, имя которого известно, следует воспользоваться утилитой ifind.

\begin{lstlisting}
$ ifind -a -n cdpocket.pdf -f fat -i raw -o 0000000032 1.img 8
\end{lstlisting}


Результатом является смещение файла, которое требуется для его извлечения.
Всё, в наших руках вся информация о файлах - осталось их извлечь. Посмотрим, например, на файл cdpocket.pdf, для извлечения которого используем утилиту icat:

\begin{lstlisting}
$ icat -f fat -i raw -o 0000000032 1.img 8 > cdpocket.pdf
\end{lstlisting}


В текущем каталоге после выполнения этой команды появляется файл cdpocket.pdf - читается и просматривается соответствующей программой.


\section{Глубокий анализ данных, Эпизод 3: повреждённые разделы}
Проблема: флеш-накопитель или винчестер не монтируются, в логах соообщения о повреждении таблицы разделов - что делать?
Решение: программа Testdisk может серьёзно помочь в деле восстановления убитых разделов в Линукс.

\subsection{Ситуация}
Мне нужно было перепрошить DVD-привод, о чём я уже писал ранее. После того, как всё удачно завершилось, мне нужно было перезагрузиться. Конечно, всё было выполнено в штатном режиме: shutdown -r now и всё шло нормально. Однако после перезагрузки мой 400Гб винчестер, который обычно висит на /dev/sdc1, монтироваться отказался наотрез. Я пошёл искать правды в логах dmesg:

\begin{lstlisting}
kernel: scsi1 : ata_piix
kernel: Vendor: ATA Model: WDC WD360GD-00FL Rev: 31.0
kernel: Type: Direct-Access ANSI SCSI revision: 05
kernel: Vendor: ATA Model: WDC WD2500JD-00H Rev: 08.0
kernel: Type: Direct-Access ANSI SCSI revision: 05
kernel: Vendor: ATA Model: WDC WD4000KS-00M Rev: 07.0
kernel: Type: Direct-Access ANSI SCSI revision: 05
\end{lstlisting}

винчестер ядро видит, и даже верно определяет его объём - значит, это не шлейф отошёл, и всё гораздо хуже. А вот и проблема:

\begin{lstlisting}
kernel: SCSI device sdc: 781422768 512-byte hdwr sectors (400088 MB)
kernel: SCSI device sdc: drive cache: write back
kernel: SCSI device sdc: 781422768 512-byte hdwr sectors (400088 MB)
kernel: SCSI device sdc: drive cache: write back
kernel: sdc: unknown partition table
\end{lstlisting}

Всё, приехали - на винчестере нет разделов! Попытка примонтировать /dev/sdc приводила к:

\begin{lstlisting}
EXT3-fs error (device sdc): ext3_check_descriptors: Block bitmap 
for group 880 not in group (block 0)!
EXT3-fs: group descriptors corrupted !
\end{lstlisting}

Да, не весело. Сокраментальный вопрос: что делать!?

\subsection{Поиск ответа на извечный вопрос}
Восстанавливаем разделы с помощью testdisk
Собственно, apt-get install testdisk был проделан давно, и от рута запускаем:
\begin{lstlisting}
# testdisk
\end{lstlisting}

% % Лицензия на материалы этого текст
% 
% Материалы сайта "Записки дебианщика" написаны virens и доступны на условиях лицензии Creative Commons Attribution-Non-Commercial-Share Alike 3.0 Unported License. Вы можете копировать, распространять, показывать эту работу, и создавать производные работы в некоммерческих целях на условиях:
% 
% 1) обязательной ссылки на автора (virens, http://mydebianblog.blogspot.com/) и
% 
% 2) распространении любых производных работ на условиях этой же лицензии (ссылка на эту лицензию 
% обязательна!).
% 
% Пожалуйста соблюдайте условия лицензии.
% 
% This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. 
Программа работает в интерактивном режиме, выводя все партиции. Так что будьте предельно осторожны! Будут выведены все подключённые дисковые накопители:

\includegraphics[width=0.9\linewidth]{pictures/testdisk4.eps}

Так, заходим дальше, на устройство с повреждённой партицией. Программа напишет, что повреждение имеет место быть и предложит проанализировать таблицу разделов. Естественно, соглашаемся. Работать testdisk будет пропорционально объёму винчестера: будет произведён поиск резервных копий информации о структуре данных. Если вам повезёт, то копии будут найдены и будет предложено записать на диск изменения. Записываем. После этого предлагается перезагрузиться, чтобы изменения вступили в силу (забытое действие, которое реализуется shutdown -r now :-))

После этого система загрузилась и подмонтировала диск, как будто ничего и не было. Даже никаких сообщений типа "transactions replayed". Данные в полном порядке - в общем, как будто ничего и не было.



\section{Отчего умирают винчестеры: небольшой обзор причин выхода из строя жёстких дисков}
Он есть у каждого из нас. Он - наше всё в прямом смысле слова, маленький кусочек высоких технологий и точной механики, на котором хранятся наши бесценные данные: фотографии, тексты, фильмы, музыка, конфиги и собственно операционная система. Это - Винчестер. Но рано или поздно, он выходит из строя - почему?

Так или иначе, я старался внимательно следить за хитросплетениями мыслей авторов статей и смог-таки кое-что выцедить оттуда.


\subsection{Причины, статистика, анализ}
Итак, статья "Failure Trends in a Large Disk Drive Population" проливает немного света на причины выхода из строя винчестеров на серверах Гугл - авторы собирали данные в течении полутора лет (с декабря 2005 по август 2006) с почти 100.000 винчестеров, диски были SATA и ATA, 5400 и 7200 RPM, ёмкостью от 80 до 400Гб разных производителей.

Главное, на что упирают гугловцы, что SMART - вовсе не панацея от всех бед и что ориентирование только на данные SMART в большинстве случаев (особенно индивидуальных) ничего не даёт. Большая часть их дисков померли в то время, как по SMART они были совершенно здоровы и без каких либо сообщений об ошибках.

Сообщается также, что вероятность гибели винчестера слабо связана с его степенью загруженности. Но если SMART сыплет ошибками типа scan errors, reallocation counts, offline reallocation counts, and probational counts - дело дрянь и пора делать бекапы :-)

\subsubsection{Возраст}
Вероятность отказа, как и следовало ожидать, растёт с возрастом диска, то есть с тем временем, которое он отработал. Диски, работающие до 1 года, чаще всего дохнут в первые три месяца. Резкий скачок вероятности выхода из строя - 2 года.


\subsubsection{Производитель}
В исследовании говорится, что, вопреки расхожему мнению, выход из строя жёсткого диска слабо зависит от того, кто произвёл этот диск, а больше зависит от конкретного экземпляра и в меньшей степени от того, в каких условиях он эксплуатируется. В доказательство они приводят тот факт, что данные по сбоям, регистрируемым SMART, почти не зависят от того, диски чьих производителей анализируются.


\subsubsection{Нагрузки}
Дальше они приводят данные по зависимости смертности дисков от степени их загруженности (т. е. от дисковых операций).

\includegraphics[width=0.9\linewidth]{pictures/disk_failures-AFRfromYear}

Оказывается, что только очень новые (до 3 месяцев) и очень старые (старше 3 лет) чаще всего дохнут от высоких нагрузок, в остальных возрастных категориях вероятность выхода из строя от нагрузок зависит слабо.


\subsubsection{Температура}
Считается, что температура - важнейший фактор для жёсткого диска и что лучше диски охлаждать. Здесь главное не дойти до маразма: температура винчестера ниже 15 градусов по Цельсию удваивает среднюю частоту выхода их из строя.

\includegraphics[width=0.9\linewidth]{pictures/disk_failures-AFRfromYear}

Гугловцы выяснили, что с повышением температуры винчестера риск отказа растёт медленно - хуже того, есть тенденция к тому, что дискам больше страшны низкие температуры. Интересно, что минимальный риск выхода из строя приходится на интервал температур от 36 до 45 градусов. Риск выхода из строя при температурах меньше 25 градусов почти вдвое больше, чем при 45, и возрастает быстро с уменьшением температуры.

Диски возраста до 2 лет чаще дохнут от холода (при температуре от 15 до 30 градусов), а старики (от 3 лет) мрут от перегрева (более 45 градусов).




\subsection{Анализ данных SMART}
Самые важные ошибки, на которые следует обращать внимание: Scan Error, Reallocation Count Offline reallocation Probational Count

\subsubsection{Ошибка сканирования (Scan Error).}
Электроника диска время от времени сканирует поверхность диска незаметно для пользователя и передаёт данные SMART - если будут найдены битые сектора, они, как правило, вскоре будут заменены на свободные. Однако гугловцы говорят: после первой же ошибки сканирования поверхности, вероятность выхода из строя винчестера в следующие 60 дней возрастает почти в 40 раз!


\subsubsection{Количество перемещений (Reallocation Count).}
Если при чтении информации возникают ошибки ввода-вывода и операционная система о них сообщает, такие ошибки перехватываются SMART и сбойный сектор заменяется нормальным из набора доступных. Количество перемещений отражает износ поверхности, однако это ещё не повод бить тревогу: около 90\% гугловских винчестеров имеют отличное от нуля количество перемещений, хотя при этом годовая вероятность сбоя (Annualized Fault Rate, AFR) повышается в 3-6 раз. После первого же перемещения сбойного участка, вероятность выхода из строя в следующие 60 дней увеличивается в 14 раз.


\subsubsection{Остальные ошибки} (в том числе Seek Error) не дают заметного вклада в общую статистическую картину дисковой смертности. Примечательно, что, например, выход диска из строя слабо соотносится с количеством циклов "старт-стоп". Однако если диску более 3 лет, следует его использовать непрерывно, так как частых включениях и выключениях вероятность выхода из строя повышается на 2\%.

В общем, гугловцы призывают не уповать на SMART и его в общем не высокую предсказательную силу (более 56\% всех умерших дисков не имели отметок об ошибках SMART), а больше налегать на бекапы и резервирование, чем почти никто не занимается, пока жареный петух не клюнет в известное место.

На десерт - самое вкусное: распределение вероятностей ошибок по данным SMART. На кладбище гугловых винчестеров винчестеры встречаются со следующим распределением сбоев:

    Ошибки, которые SMART не отловила - 60\%

    Reallocation Count - около 40\%

    Seek Error - 30\%

    Offline Reallocation - 28\%

    Probe Count - 20\%

    Scan Error - 15\%

    CRC Error - менее 5\%.

Ясно, что винчестеры дохнут не от одной ошибки, а чаще всего от нескольких, лидирует в которых сбойные сектора и ошибки позиционирования.

Следует отметить, что в винчестерах отдельных производителей \verb+Raw_Read_Error_Rate+ и \verb+Seek_Error_Rate+ параметры достигают максимума и обнуляютя несколько раз в день. Это связанно с политикой некоторых производителей в отношении SMART: в эти параметры пишутся все ошибки, а остальные производители только те, что не смог отловить контроллер.



\subsubsection{Время наработки на отказ}
Другая статья, "Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?", подробно разбирает, что такое MTTF, или mean time to failure. Статистика также очень впечатляющая (около 100.000 устройств).

Многие производители оценивают отказоустойчивость двумя связанными друг с другом оценками: ежегодная частота ошибок (Annualized failure rate, AFR) и среднее время отказа (mean time to failure). AFR оценивается на основе предсказаний по результатам ускоренных тестов, а MTTF оценивается как время работы за год делённой на AFR. Ведущие производители дисков заявляют, что MTTF их устройств - от 1 млн. часов до 1.5 млн. часов в соответствии с AFR равной 0.58\% и 0.88\% соответственно.

В статье говорится о том, что их данные о частоте замены винчестеров ввиду сбоев, мягко говоря, расходятся с тем, что заявляет производитель. Так, в трёх дата-центрах, в которых снимались данные для этой статьи в течение 5 лет, в общем случае замены жёстких дисков в связи со сбоями были несколько чаще, чем замена планок оперативной памяти, в 2.5 раза чаще, чем замена процессоров, в 2 раза чаще, чем замена материнских плат. Факт остаётся фактом: сбои винчестеров - одни из самых распространённых причин остановки узлов дата-центров для замены оборудования.

Дальше в рамках исследования было вычислено значение ежегодной частоты ошибок (AFR) для всех датацентров, в которых это исследование проводилось, и вот график:

\includegraphics[width=0.9\linewidth]{pictures/schroeder-AFR}

Он стоит тысячи слов: горизонтальная сплошная прямая соответствует заявляемым 1.5 млн. часам безотказной работы, горизонтальная пунктирная - 1 млн. часов, а точечная - реальному усреднённому времени работы. Согласно этому, AFR составляет 3\%, а соответствующее MTTF - около 300 тыс. часов.


Разброс таких данных велик: AFR составляет от 0.5\% до 13.6\%, и это в дата-центрах. Последняя цифра соответствует примерно 7 годам работы винчестера, но понятно, что в бытовых устройствах эта цифра намного скромнее: постоянно меняющаяся температура устройства, небольшое время непрерывной работы, скачки напряжения, большое количество циклов "старт-стоп" и прочее сильно сокращают время жизни жёстких дисков.

Ещё один замечательный график, показывающий жизненный цикл жёстких дисков в зависимости от времени работы:

\includegraphics[width=0.9\linewidth]{pictures/schroeder-lifecycle}

Интересные выводы в работе такие:

   1. MTTF, которое заявляет производители, более чем в 3 раза превосходит тот, который оценен в реальных условиях дата-центров.

   2. Для старых винчестеров, отработавших 5-8 лет, переоценка MTTF производителями составляет более 30 раз.

   3. Даже для сравнительно новых жёстких дисков (менее 3 лет работы) MTTF производителем завышена по крайней мере в 6 раз.

   4. Частота замен для дорогостоящих SCSI-дисков и обычных SATA почти одинакова.

И далее по работе: Для дисков, чьё время непрерывной работы менее 5 лет, частота замены в связи со сбоями в 2-10 раз больше той, которая следует из времени MTTF, а для старше 8 лет эта частота замен в 30 раз больше.


\subsection{Как просмотреть информацию SMART}
Для этого уже должны быть установлен пакет smartmontools, который содержит в том числе утлиту smartctl. После этого:

    * для IDE-дисков пишем smartctl --all /dev/hda

    * для SCSI-дисков smartctl --all /dev/sda

    * для SATA-дисков smartctl --all -d ata /dev/sda

Будет выведена длинная таблица, в которой будет много интересного.

% % Лицензия на материалы этого текст
% 
% Материалы сайта "Записки дебианщика" написаны virens и доступны на условиях лицензии Creative Commons Attribution-Non-Commercial-Share Alike 3.0 Unported License. Вы можете копировать, распространять, показывать эту работу, и создавать производные работы в некоммерческих целях на условиях:
% 
% 1) обязательной ссылки на автора (virens, http://mydebianblog.blogspot.com/) и
% 
% 2) распространении любых производных работ на условиях этой же лицензии (ссылка на эту лицензию 
% обязательна!).
% 
% Пожалуйста соблюдайте условия лицензии.
% 
% This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. 
